package cn.anquing.principle.lowOfDemeter;


/**
 *迪米特法则:也叫做做最少知识原则（Least Knowledge Principle，简称 LKP）说的都是一会事，一个对象应该对其他对象有最少的了解，通俗的讲一个类对自己需要耦合或者调用的类应该知道的最少，你类内部是怎么复杂、怎么的纠缠不清都和我没关系， 那是你的类内部的事情，我就知道你提供的这么多 public 方法，我就调用这个；
 *迪米特法则包含以下四层意思：
 *1、只和朋友交流,迪米特还有一个英文解释叫做“Only talk to your immedate friends”,出现在成员变量、方法的输入输出参数中的类被称为成员朋友类
 *2、朋友间也是有距离的,迪米特法则就要求类“小气”一点，尽量不要对外公布太多的 public 方法和非静态的 public 变量， 尽量内敛，多使用 private,package-private、protected 等访问权限
 *3、是自己的就是自己的，在项目中有一些方法，放在本类中也可以，放在其他类中也没有错误，那怎么去衡量呢？你可以坚持这样一个原则： 如果一个方法放在本类中，即不增加类间关系，也对本类不产生负面影响，就放置在本类中
 *4、谨慎使用 Serializable，实话说，这个问题会很少出现的，即使出现也会马上发现问题。是怎么回事呢？
 *  举个例子来说，如果你使用 RMI 的方式传递一个对象 VO（Value Object），这个对象就必须使用 Serializable接口，
 *  也就是把你的这个对象进行序列化，然后进行网络传输。突然有一天，客户端的 VO 对象修改了一个 属性的访问权限，
 *  从 private 变更为 public 了，如果服务器上没有做出响应的变更的话，就会报序列化失败。
 *  这个应该属于项目管理范畴，一个类或接口客户端变更了，而服务端没有变更，那像话吗？！
 */

/**
 * 迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高，其要求
 的结果就是产生了大量的中转或跳转类，类只能和朋友交流，朋友少了你业务跑不起来，朋友多了，你项
 目管理就复杂，大家在使用的时候做相互权衡吧。
 */
public class Client {
}
